This "must evaluate to" cannot be validated during admission time (depends on unknown input types).

How are evaluation errors at runtime handled?

Ah yes I should have clarified this. Missed including it here but my thoughts were to have the same behaviour as CELDeviceSelector. Precisely this

I've update the KEP to that effect.

Nit: I know I suggested +k8s:optional as replacement for +optional earlier, but since then I learned that both are needed (the former for declarative validation, the latter for OpenAPI).

No worries. Updated with +k8s:optional

Nit: let's just say "which carries the same properties as in a CELDeviceSelector`?

For example, allowMultipleAllocations probably will be available (why should it not be?), but isn't described here.

Sure, updated the statement to:

	// The expression's input is an object named "device", which carries the
	// same properties as in a CELDeviceSelector.

Instead of doing this in test/integration/scheduler/dra, do this in test/integration/scheduler_perf/dra/derived-attributes (new folder). Make sure to include a realistic scenario (number of attributes, complexity of the CEL expressions), then define a simple case for correctness checking and larger cases for performance measurement.

See consumable capacity (currently being updated in kubernetes/kubernetes#139511 because we didn't do that well initially).

With that done I don't see a need to add more testcases for this to test/integration/scheduler/dra.

Thanks. Updated the directory and things to keep in mind during implementation.

This is what you'll need the scheduler_perf cases for.

Thanks, updated a reference to the scheduler_perf test discussed in the other comment.

why kubelet?

My bad. You did ask me to clean this up from the PRR but I missed cleaning it up here. Removed now.

Also cover distinctAttribute

Explicitly worded distinctAttributes too.

it should apply to anything in constraints, not just matchAttribute. Today that means also distinctAttribute.

Also: can derived attributes be used in device request CEL selectors? ie, are they evaluated BEFORE or AFTER the selectors?

That's a good point. In CEL expressions, the derived attributes aren't really needed (the expression itself can embed the necessary mapping). But it would be more consistent and perhaps even expected if they were present. I'm +1 for that.

Thanks @johnbelamaric and @pohly! The use of derivedAttributes within CELDeviceSelector is something I've thought about, but intentionally did not include in this KEP.

My main reason for keeping it out of scope—as you both noted—is that it isn't strictly necessary. If a user needs that logic in the selector, the CELDeviceSelector can just embed the necessary mapping directly. Attempting to include derivedAttributes into selectors brings additional complexities, such as how they impact performance by forcing early evaluation, and how they should be referenced in the CEL environment (i.e. whether we add them to device.attributes or have to introduce a new device.derivedAttributes map)

Perhaps earlier in the KEP cycle we could have had these discussions in detail, but seeing as we're close to the KEP deadline, I'd rather avoid introducing this change without more careful consideration. If this usability experience is needed in the future, a different KEP would be a perfect opportunity to explore that avenue. Hope you both share the same thoughts :)

With that in mind, I've added this bit of clarification:

- **Evaluation Order**: Derived attributes are evaluated **after** the device
  request's `CELDeviceSelector` has filtered candidate devices. They are not
  injected into the selector's CEL environment and are exclusively used for
  evaluating constraints like `matchAttribute` and `distinctAttribute`.

and also added a separate section ## Future Considerations > ### Derived Attributes in Device Selectors on the current rationale and future improvement through a separate enhancement (if needed)